Skip to main content

Continuous Assurance Policies

Document Purpose​

To outline the logical model needed to support continuous assurance policies.

To identify the key entities and relations

To define the method of expression and the method of communication in order to implement Realtime distributed policy enforcement.

Problem being addressed​

How do we securely express and transmit the underlying policy information, implicitly embodied in the documented brksi flows

How do we map these to asynchronously evaluated expressions

This assumes

a. the abstract polices are useful

b. the mappings to BRKSI flows are more or less correct

Entities​

For a real-time system for onboarding devices onto a network and managing the full Lifecyle, we can identify the following basic entities

  • Network instance: the entity managing a single instance of a network connectivity
  • Device instance: a specific instance of a device connecting to a network
  • Registrar (BRSKI name): the logical controller of one or more network instances - and the policy enforcement point

We then have the following additional properties

  • A network: a logical entity comprising many network instances under the control of a regsitra
  • A device manufacturer:
  • A device type:
  • A device software version/firmware
  • A device owner
  • A device ownership tree
  • A network instance owner
  • A network instance owner tree
  • A registrar owner
  • A registrar owner tree

Entity relationship cardinalities and temporal properties​

What does the object model look like?

  • Network controller

    • Network owner (tree)

    • Network manufacture

      • Network supply chain

  • Registrar ( groups of network controllers)

    • Registrar owner (tree)

  • Device

    • Device owner (tree)
    • Device manufacturer

Policies need reframing in relation to this dynamic object model.

Expression short hand​

Using the normal shorthand expression of the form

Relation(entity1@, entity2+) : [signatory-]

Where

  • Relation: is the relation holding between one or more entities
  • entitiy1@: identifies an entity using an indirect expression - such as a URI
  • entitiy1+: identifies an entity using an direct public key reference
  • signatory-: identifies the private key of the entity acting as a signatory of the expression

Expression embodiment​

The expression can be embodied in many ways

  • A standard X509 certificate
  • JSON/JOSE structure with proof of possession
  • W3C verifiable credential
  • CMS
  • Signed CBOR

most can be proven to be fundamentally interchangeable with respect to the essential primitives.

Expression communication​

If the expression are embodied correctly, the end to end system can work fairly independently of the bearer method. Anthing form HTTPS tot WebSocket to raw TCP to DTLS. Email can potentially be supported The system should support airgapped communication using USB drives

Ideally the expression should include issue date and time to-live attributes (e.g VCs)

Ideally the expression should include issuer URIs, in order that the policy enforcer can request updates directly

Policy mappings

Registrar->Network controller mapping​

We will assume the policy decision point is equivalent to the registrar in the BRWSKI flows.

We will assume a single registrar is mapped to multiple network controllers

​ Owned-by(network-controller+,registrar) : []